Data Acquisition Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

As documented in a previous post, it is currently impossible to install the nidaqmx-python library into a Docker container. Enabling this functionality would create an opportunity for software teams to build cutting edge big data pipelines for measurement instruments using container technology. This could also optimize development time by including custom DAQ code in continuous integration pipelines.

For some time a few Mac and Linux users are complaining to me that they want DAQmx on the Mac and Linux. This makes LabVIEW more cross platform compatible and enables the users to use their measurement equipment to it's full potential. The Mac market share hits about 10% and Linux about 2% this seems to be a growing market. And mosth netbooks use linux as an os, therefore this will make excelent portable measurement station. This will open a new market for National Instruments and for LabVIEW programmers.

I have a hard time explaning to clients that the little application that just monitors a few AI channels requires a huge (several 100'sMB) installer to run.  It would be nice to allow for a small subset of daqmx to work.  Maybe there is a way of doing this or maybe it is way too hard, but it would be nice to have the ability to filter support for devices and daq type on the drivers installation.

 

IE:

install only 6609 or 6008 AI only support where the installer would be a small fraction of the current size.

 

 

Dear NI, please consider a future hardware feature addition:

 

Add a "Power Up Delay DIP Switch" to the back of the PXI Power Supply Shuttle.

 

It would allow end users to reliably sequence the powering-up of multi PXI chassis solutions. It could also be handy to sequence any other boot-order sensitive equipment in the rack or subsystem. This would also be a world-voltage solution since this capability already exists in the power shuttle. We are seeing the need for more input-voltage-agnostic solutions. I'm sure you are too.

 

It might offer time delay choices of 1,2,4,8,16 seconds, etc.

 

We run into this problem on every multi-chassis integration. We have solved it several ways in the past like: human procedure (error prone), sequencing power strips ($$$ and not world-voltage capable), custom time-delay relays ($$$).

 

Imagine never having your downstream chassis(s) disappear. Or worse yet, having them show up in MAX, but act strangely because of not enough delay time between boots.

 

Thanks for reading this, and consider tossing me a Kudos!

"Without needing to clear "all" associated events, or EVEN opening MAX, I would like the ability to replace NI-USB Device "Doohickey123" serial number "junkgarbagestuff" with another NI-USB device of the same type-  perhaps a pop-up option like.... ""Replace no longer installed NI-53xx alias "gizmo"  with new NI-53xx?""  

 

Sure would help when I swap NI-xxxx devices amongst systems- especially the USB devices!

Dear NI, please consider a future hardware feature addition:

 

Add a "Power Up Delay DIP Switch" to the back of the PXI Power Supply Shuttle.

 

It would allow end users to reliably sequence the powering-up of multi PXI chassis solutions. It could also be handy to sequence any other boot-order sensitive equipment in the rack or subsystem. This would also be a world-voltage solution since this capability already exists in the power shuttle. We are seeing the need for more input-voltage-agnostic solutions. I'm sure you are too.

 

It might offer time delay choices of 1,2,4,8,16 seconds, etc.

 

We run into this problem on every multi-chassis integration. We have solved it several ways in the past like: human procedure (error prone), sequencing power strips ($$$ and not world-voltage capable), custom time-delay relays ($$$).

 

Imagine never having your downstream chassis(s) disappear. Or worse yet, having them show up in MAX, but act strangely because of not enough delay time between boots.

 

Thanks for reading this, and consider tossing me a Kudos!

 

 

When I want to do an installation build of my project, I have to include the whole NI-daqmx into my build in order to insert my (in this case) USB-6251-driver. Thus my install package expands from about 150 MB to more than 1 GB. This is way to much!

 

It would be nice to be able to choose only the wanted driver (in my example the NI-6251 and the SCC68) in the "adding additional driver's" menu and just add this one to the distribution instead of "adding them all".

The DAQ Assistant was presumably created to simplify data acquisition.  The idea seems to be to put all of the needed pieces in one place, so that all the low level 'traditional' DAQ vi functions are not needed.

 

Consider the following simple vi:

 

Demo VI

 

This could be as simple as one analog input channel.

 

The program will compile into an .exe and work just fine, as long as you don't use one of the features of the DAQ Assistant:  Custom scales.

 

Custom scales are not stored with the VI or project, but in a system file that does not automatically get included in an .exe build.  The .exe will work fine on the original PC that built it, but it will not work when the .exe is loaded on a different PC.

 

There is a method that allow the user to port the custom scales to another PC, but it is not automatic.

 

http://digital.ni.com/public.nsf/allkb/12288DEB3C6A185B862572A70043C353

 

 

The fundamental problem is that the DAQ Assistant is intended to make life simple and give you everything you need to make a program.  Custom scales are included in the DAQ Assistant so that the programmer does not need to manually create scaling in their vi.  But what good does that do if they are not included in the .exe build, and there is no obvious clue that this requires extra work or what that work is?

 

The build .exe process needs to be upgraded to automatically include custom scales and possibly other MAX settings that are essential to the operation of a compiled program.  It does not matter if the build process ciphers and includes only the specific scales or setting used by the particular program / vi, or if it just takes all the settings. 

 

These are critical pieces to make the final compiled program run on another machine.  The user should not have to somehow know that these pieces are separate but need to be included, and have to take extra steps to go out and select them in order for them to be used in the build.  That is totally counter intuitive to the simplicity intended by the DAQ Assistant.

Currently my entire school district is going 1:1 with chromebooks for your students. This is also happing in many other schools around the country. It would be awesome if you could develop a way for your programs to be based off a "cloud". This would allow for students to use the programs at home and in different locations around the school, not just a "computer lab" that has the software loaded onto it. 

I'm not sure who reads this, but I'm not seeing any feedback in the forum so I thought I'd post up here.   This may seem like a simple thing, but hopefully my pain will be someone else gain.  I messed with this off and on for two months before I finally figured it out.  It's probably obvious to those who work with this equipment every day and have EE degrees, but not so much to those of us who do not. 

 

Please see http://forums.ni.com/t5/Multifunction-DAQ/Measuring-220VAC-with-CompactDAQ/td-p/1145956 for a description of the issues I was having. 

 

Some will tell me to "search"... well, I did.  ...and everywhere I looked all I found was that I needed to measure from the power leg to ground.  All of the examples either were only measuring 120 which is fine since what you have is one power leg and neutral... which is basically ground!  So those numbers come out fine.  Or they were for 3 phase, which I don't use currently.  BUT when you try and measure anything with two power legs (basically anything between 208VAC to 240 VAC) the numbers don't work out right if you try to measure between each power leg to ground and then try to recombine them and plug them into the Power VI's.  Not one place that I looked did it tell me that I need to measure both power legs across a single channel.  I only finally tried it because I'd done pretty much everything else.  I know this is pretty basic stuff, but when all you give me says one thing... that's what we do.  Just trying to help others.

Thanks,

Chad

TO

 

R&D , LABVIEW,

NATIONAL INSTRUMENTS.

 

FROM

 

Mithun Raj .T,

Pranavam, Kalluvilla , Kariyam,

Sreekaryam P.O, Trivandrum- 17,

Kerala, India.

 

We are a group of B.tech project students from SIST , Kerala ,India. We are doing a project on ICU using LABVIEW in Indian Space Research Organisation.

While we doing our project we found the nessecity of following :

 

> A functions that provides range or specification of the addressed device so that the programmer has an overall knowledge of the addressed device & its range of operation.

> A suggestion window at the top left when some error occurs.

 

So if our suggestions are good please kindly provide us a good idea certificate from NATIONAL INSTRUMENTS,that will help us a lot. So kindly consider our request.

 

Your's affectionatly,

 

Ahammed Shiraz A.R

Anish .S

Dileesh .S

Mithun Raj .T